Recent advances in computer performance have enabled graphic systems to provide more realistic graphical images using personal computers and home video game computers. In such graphic systems, some procedure must be implemented to “render” or draw graphic primitives to the screen of the system. A “graphic primitive” is a basic component of a graphic picture, such as a polygon, e.g., a triangle, or a vector. All graphic pictures are formed with combinations of these graphic primitives. Many procedures may be utilized to perform graphic primitive rendering.
Texture mapping schemes were developed to enhance the images rendered by early graphics systems. Early graphic systems displayed images representing objects having extremely smooth surfaces. That is, textures, bumps, scratches, or other surface features were not modeled. In order to improve the quality of the image, texture mapping was developed to model the complexity of real world surface images. In general, texture mapping is the mapping of an image or a function onto a surface in three dimensions. For example, the texture would be a picture of whatever material the designer was trying to convey (e.g., brick, stone, vegetation, wood, etc.) and would contain shading information as well as the texture and color to create the impression of a complex, dimensional surface. Texture mapping is now widely established and widely implemented in most computer graphics systems.
Modem realistic texture mapping (e.g., as required for modem 3D rendering applications) requires the manipulation of large amounts of data. Generally speaking, as a given 3-D scene becomes more realistic, the more realistic the texture map (or simply texture) being used in the texture mapping operations. Accordingly, realistic high-resolution textures can be very large (e.g., several megabytes of data). The bandwidth required for accessing such textures is also very large. The memory and bandwidth requirements can exceed the capabilities of even the most modem real-time 3-D rendering systems.
One prior art approach to alleviating texture memory and bandwidth requirements involves the implementation of various schemes whereby only certain textures that may be needed in a scene are fetched from memory on an as-needed basis. The textures are typically stored in system memory, as opposed to local graphics memory. To satisfy the bandwidth requirements and latency constraints, only those textures required by a certain scene are fetched into the local graphics memory and used in the texture mapping operations of the 3-D rendering process. Generally, the local graphics memory is much smaller than the system memory of the computer system.
For example, one prior art scheme only fetches those textures that are needed to render the visible scene (e.g., that portion of the scene within the view volume). As the scene changes (e.g., as the viewpoint of the view volume changes), other textures, or portions of very large textures, are fetched as required. This technique relies on a texture swapping mechanism to fetch needed texture data when that data is not resident in local graphics memory. These types of prior art approaches seek to keep the most frequently accessed textures within the faster local graphics memory. For example, swapping a “texture A” out of local graphics memory in favor of a more frequently used “texture B” in system memory involves allocating a memory block C in system memory of the same size as texture A and then copying texture A into texture C. Then texture A is de-allocated from the local graphics memory, and a memory block D of the same size as texture B is allocated into the local video memory freed by the de-allocation texture A. Texture B is copied from system memory into memory block D and is texture subsequently de-allocated from system memory. Of course, texture A must be at least as large as texture B.
One problem with this approach is the fact that it is generally space wise inefficient when swapping blocks of texture data between system memory and local graphics memory. For example, if the blocks of texture data are not the same size (e.g., texture block B in system memory is not the same size as texture block A in local graphics memory), memory fragmentation will occur. The different size blocks of texture data will lead to fragmentation of the limited amount of local graphics memory available to a graphics processor.
Yet another problem with this approach involves the fact that calls to allocate/destroy memory blocks generally must be implemented through the operating system. This involves a series of calls to the operating system by, for example, a graphics driver, to allocate and de-allocate blocks of memory. Such calls and context switches to the operating system are very slow in comparison to the execution of a graphics application.
The above problems increase the time required to service the texture block transfers. This delay can cause stalling of the graphics rendering pipeline. Such stalling is very harmful to real-time 3D rendering applications. The stalling often leads to choppy frame rates and other noticeable pauses when new texture data must be fetched.
Some 3D rendering applications are especially dependent on smooth and reliable access to needed texture data. For example, MIP mapping generally requires several versions of a given texture to be stored and available in local graphics memory (e.g., a full resolution version and several lower resolution versions of a texture), and hence, texture memory demands tend to be high. In a highly dynamic rendering environment where the rendered scene changes rapidly, high bandwidth low latency access to the texture data is critical to overall performance. Stalling the 3D rendering pipeline due to prior art texture block swapping rapidly leads to choppy frame rates, noticeable pauses, and similar problems as the rendered scene changes.
One prior art solution to maintaining rendering speed and frame rate is to increase the amount of local graphics memory (e.g., 128 Mb, 256 Mb, 512 Mb, etc.). Such an approach is expensive and does not improve the performance of older graphics cards having less installed local graphics memory. Another prior art solution is to increase the performance of the memory management sub-system. This approach is also expensive, in that it can require expensive high speed components (e.g., multi channel system memory, exotic high speed DDR RAM, PCIx graphics bus, etc.). Even with such components, however, there are practical limits to the degree to which the performance of the prior art texture block swapping schemes can be improved. Thus, what is needed is a more efficient way to maintain rendering speed and frame rate for those 3D rendering applications that utilize texture mapping.